État des lieux de la sécurité open source 2023

Les cyberattaques ont beau être chaque année plus nombreuses et se concentrer toujours plus sur le code open source, beaucoup des entreprises que nous avons interrogées n’utilisent toujours pas les deux technologies les plus importantes pour la sécurité de la chaîne d’approvisionnement, à savoir l’analyse de la composition des logiciels (SCA) pour les dépendances open source et les tests de sécurité des applications statiques (SAST) pour les implémentations non publiques de code open source et propriétaire. Les mesures de sécurité cloud-native, comme les vérifications de la configuration des outils d’infrastructure en tant que code et l’analyse des secrets, sont encore moins répandues.

La vérification de la posture de sécurité des paquets open source est essentielle pour maintenir la sécurité de la chaîne d’approvisionnement logicielle. Les systèmes automatisés qui vérifient que les paquets respectent les meilleures pratiques, comme Snyk Advisor ou OpenSSF Scorecard, constituent le moyen le plus fiable d’analyser le risque de manière programmatique. Pourtant, ces systèmes sont les moins utilisés dans cette optique. Seules 40 % des personnes interrogées utilisent Snyk Advisor, et 34 % des scores de sécurité.

De manière assez étonnante, seuls 52 % des participants à notre enquête affirment vérifier que tous les paquets qu’ils utilisent bénéficient d’une politique de « divulgation responsable », un point pourtant incontournable.

De nombreuses entreprises souhaitant améliorer de manière proactive la sécurité de leur code et réduire le nombre de vulnérabilités qui s’y sont glissées au cours du développement cherchent à impliquer davantage les développeurs dans la sécurité (stratégie shift-left)t . Cette stratégie optimise la vitesse et l’efficacité du cycle du développement logiciel, car moins de builds sont bloquées lors des tests pré-déploiement et renvoyées aux développeurs pour correction. Pourtant, elle n’est que partiellement mise en place. Seules 40 % des personnes interrogées affirment que leur entreprise déploie des outils de sécurité au sein de ses environnements de développement, et elles sont encore moins nombreuses à les utiliser en local sur la ligne de commande.  Le plus souvent, les outils de sécurité sont intégrés aux outils de build et dépôts de code, cités tous deux par 65 % des répondants.

Les réponses à notre enquête indiquent que cette crise est bien réelle et a des conséquences variées pour les entreprises. Une grande majorité des répondants a rencontré un ou plusieurs problèmes en lien avec la chaîne d’approvisionnement l’année dernière. 53 % ont dû corriger au moins une vulnérabilité, et 61 % ont déployé de nouveaux outils et meilleures pratiques de sécurisation du code open source et de la chaîne d’approvisionnement. Ces chiffres montrent que beaucoup d’entreprises ne se décident à agir que lorsqu’une attaque les touche directement. 

L’adoption des meilleures pratiques de sécurisation de la chaîne d’approvisionnement logicielle reste hétérogène. Seules 53 % des entreprises ont mis en place un programme officiel à cet effet. Il est possible que la sécurité de la chaîne d’approvisionnement soit considérée comme un composant des pratiques générales en matière de sécurité, mais ce chiffre pose néanmoins question. La sécurité de la chaîne d’approvisionnement est-elle vraiment devenue un sujet pressant pour les entreprises, ou tout au moins suffisamment important pour mériter une réflexion et une planification à l’échelle d’un programme ? Pour entrer dans le détail de ces pratiques, seules 42 % des entreprises utilisent des nomenclatures de logiciels (SBOM), 58 % déploient des signatures pour l’attribution du code et 62 % mettent en place un processus d’assurance du cycle de vie logiciel (comme le SLSA).

Les types des vulnérabilités ignorées par les entreprises donnent des informations précieuses sur la surface d’attaque et les risques acceptés, que ce soit de manière consciente ou non. Le principal type de CVE ignoré par au moins 50 comptes ? Les dénis de service (DoS). Ils représentent 31,3 % des vulnérabilités ignorées. Si elles restent graves, ces attaques sont généralement contrecarrées de manière proactive par le CDN ou l’infrastructure. Assez logiquement, de nombreuses équipes ne les considèrent donc pas comme prioritaires. La désérialisation de données non fiables représente 14,3 % des CVE ignorées par plus de 50 comptes. Ce type regroupe diverses vulnérabilités pouvant toucher différents langages. Il constitue souvent la première étape d’attaques en chaîne ou composées, et constitue donc une vulnérabilité sérieuse. Le troisième type de vulnérabilité le plus courant, la pollution de prototype (12,5 %), concerne principalement la communauté JavaScript. 

Depuis la naissance de l’open source, la supériorité de sa sécurité face aux logiciels propriétaires fait l’objet de tous les débats. Les vulnérabilités sont publiques, tout comme leurs corrections. Par conséquent, il est possible de suivre le délai de correction à partir des bases de données des vulnérabilités. C’est exactement ce que nous avons fait sur une période recouvrant les quatre dernières années. Notre conclusion ? Le délai de correction moyen des logiciels propriétaires a augmenté depuis 2019, quand les applications open source suivent une tendance inverse. Pour être honnête, les deux types de logiciels réduisent leur délai de correction depuis 2021, mais pour la première fois depuis que nous suivons cet indicateur, les applications open source corrigent plus rapidement leurs vulnérabilités que les applications propriétaires. Cette tendance indique que l’écosystème open source améliore sa réponse aux problèmes de sécurité et propose peu à peu une meilleure sécurité que les solutions propriétaires.

Après un pic important, le délai de correction des vulnérabilités critiques et hautement prioritaires a considérablement diminué au cours des deux dernières années. Ce pic pourrait indiquer que l’analyse du code open source était plus fréquente ces deux années, mettant en lumière des vulnérabilités jusque-là invisibles. De 2021 à 2022, le délai de correction moyen pour ces deux types de vulnérabilité a été divisé plus ou moins par deux : -51 % pour les vulnérabilités critiques et -49,4 % pour les vulnérabilités hautement prioritaires. Cette baisse importante peut s’expliquer par différents facteurs, notamment une adoption plus large d’outils de sécurité open source comme la SCA, davantage de fonds et de ressources mobilisés pour la correction des vulnérabilités critiques, et une meilleure reconnaissance de l’importance de la sécurité au sein des projets open source. Quoi qu’il en soit, la tendance est bonne et s’oriente vers une amélioration continue de la sécurité des logiciels open source. 

Le délai de correction des vulnérabilités est variable d’un écosystème open source à l’autre, et c’est au sein des plus importants écosystèmes suivis par Snyk qu’il a le plus baissé. Les réductions les plus fortes sont enregistrées par Java et Python, avec respectivement 50,8 % et 43,4 %. Les cinq écosystèmes ayant réduit leur délai de correction ont atteint une baisse à deux chiffres. Si l’on prend en compte la réduction en jours, Go (147 jours de moins) et Python (115 jours de moins) prennent la tête du classement. Deux écosystèmes ont toutefois régressé. Ainsi, C et Ruby ont connu une hausse de respectivement 144,7 % et 102,1 % du nombre de jours moyens nécessaires pour effectuer une correction, ce qui se traduit par 55 et 49 jours en plus pour chacun de ces écosystèmes. Les écosystèmes open source améliorent leurs délais de sécurisation et, par extension, renforcent la sécurité de la chaîne d’approvisionnement en raccourcissant le temps qui s’écoule entre la publication des vulnérabilités et leur correction.